Hi Greg,
Well, it is the idea related to asset protection. I don’t want to limit IOPMP to do so only. Just like PMP, it is not only
for asset protection but also for M-mode-based isolation. There are a couple of products that have done it. Asset protection is not enough nowadays for a commercial security monitor that uses PMP, so does IOPMP. M-mode-based isolation should be taken into
consideration. Nick may remember the discussion with SESIP, Security Evaluation Standard for IoT Platform. They already required a certain type of isolation enforced by hardware.
What is the difference between asset protection and isolation? Asset protection doesn’t care about how many OSes are running
on a system. Some data should be accessed by M-mode only. PMP/ePMP and IOPMP can use a lock mechanism to enforce it. Isolation mechanism can create multiple security domains, which each domain may have its own OS. The security monitor uses a certain number
of PMP/ePMP rules to build an isolated memory space. On domain switching, it is in charge of switching PMP/ePMP rules for the next domain. The lock mechanism should not be applied. It is for switching domains within a hart. Can a bus master switch between
different security domains? It is possible!
Let’s consider a crypto engine, and we have two security domains that share this crypto engine. When Domain-A OS needs the
crypto engine, the security monitor should “grant” it to Domain-A firstly. The detailed steps include changing PMP entries and IOPMP entries. When Domain-A finishes the crypto engine, it tells the security monitor to “release” the engine. Domain-B can “allocate”
the crypto engine afterward. The above is one of the possible ways to handle a shared DMA-based device in a security monitor. In some resource-limited systems, we may not have enough budget to equip a crypto engine for both security domains, so we should allow
sharing such a device. To do it, we will need isolation than asset protection. However, I think this part is too detailed for a charter. Thus, I didn’t limit that IOPMP can do asset protection only.
Sincerely,
Paul
toggle quoted message
Show quoted text
|
On Mon, Feb 21, 2022 at 12:02 AM Paul Ku < scku@...> wrote:
Well, it is the idea related to asset protection. I don’t want to limit IOPMP to do so only. Just like PMP, it is not only
for asset protection but also for M-mode-based isolation. There are a couple of products that have done it. Asset protection is not enough nowadays for a commercial security monitor that uses PMP, so does IOPMP. M-mode-based isolation should be taken into
consideration. Nick may remember the discussion with SESIP, Security Evaluation Standard for IoT Platform. They already required a certain type of isolation enforced by hardware.
I agree that IOPMP should address both basic protection of M-mode or single security domain resources from I/O accesses, and also protection for multiple security domains from I/O accesses. (Whereas ARM traditionally had TrustZone with just one Secure domain, even they are now moving to support multiple Secure domains.)
As a side note, SBI and the OpenSBI implementation of SBI prototyped (last year) support for multiple Secure Domains. Going forward, new RISC-V arch extensions should comprehend systems with multiple security domains - starting with IOPMP. (Or at least that's my own opinion.)
My earlier high-level one sentence summary strived to delineate what the intent of IOPMP is and is not. Which served its purpose and surfaced this gap in what should in fact also be covered by IOPMP. Here's an updated version of what I would suggest (not that these are the best exact words and wording):
IOPMP provides access control over accesses to system address space by I/O agents, under the control and management of M-mode or Secure domain software, to protect M-mode or Secure domain resources. This includes support for multiple security domains with separate access controls over I/O accesses.
Greg
What is the difference between asset protection and isolation? Asset protection doesn’t care about how many OSes are running
on a system. Some data should be accessed by M-mode only. PMP/ePMP and IOPMP can use a lock mechanism to enforce it. Isolation mechanism can create multiple security domains, which each domain may have its own OS. The security monitor uses a certain number
of PMP/ePMP rules to build an isolated memory space. On domain switching, it is in charge of switching PMP/ePMP rules for the next domain. The lock mechanism should not be applied. It is for switching domains within a hart. Can a bus master switch between
different security domains? It is possible!
Let’s consider a crypto engine, and we have two security domains that share this crypto engine. When Domain-A OS needs the
crypto engine, the security monitor should “grant” it to Domain-A firstly. The detailed steps include changing PMP entries and IOPMP entries. When Domain-A finishes the crypto engine, it tells the security monitor to “release” the engine. Domain-B can “allocate”
the crypto engine afterward. The above is one of the possible ways to handle a shared DMA-based device in a security monitor. In some resource-limited systems, we may not have enough budget to equip a crypto engine for both security domains, so we should allow
sharing such a device. To do it, we will need isolation than asset protection. However, I think this part is too detailed for a charter. Thus, I didn’t limit that IOPMP can do asset protection only.
Sincerely,
Paul
It looks like you and a set of others have done a great job establishing a clear "bottom up" delineation between IOMMU and IOPMP as far as features and requirements. This will provide good content for the IOPMP charter
to spell out its scope. I would request that the IOPMP charter also provide a succinct high-level or "top-down" statement about what it is about, i.e. "what, who, why". For example (and I'm sure you all can come up with better words and phrasing):
IOPMP provides access control over accesses to system address space by I/O agents, under the control and management of M-mode or Secure domain software, to protect M-mode or Secure domain resources.
Something like that clearly and concisely conveys the focus of IOPMP and helps bound the use cases driving the IOPMP architecture. I fully expect that there will be other use cases that will also desire something like
IOPMP, but with certain additional features or enhancements. In the new RVI expectation of divide-and-conquer (and not allowing a TG to try and boil an ocean), follow-on TG efforts can work to address these needs. Rather analogous to how the CMO TG took
all the needs and use cases it wanted to address and pared it all down to a "phase 1" subset that the first CMO arch extension accomplished last year. And now it is defining what "phase 2" should be and putting together a corresponding new charter.
On Thu, Feb 17, 2022 at 8:50 PM <mick@...> wrote:
Hello all
There have been multiple discussions and threads on various lists
regarding the overlap of IOPMP and IOMMU, and also recently on how an
IOPMP / IOMMU would work alongside a CPU with / without memory
translation. Since IOPMP/IOMMU/MPU proposals were initially submitted /
discussed on TEE TG I thought it would be beneficial to help the new TGs
with their charters by writing down what our expectations are from each
of these blocks. On our previous TEE TG call we came up with a set of
points that I’ll try to explain here in detail.
a) Static vs Dynamic rulesets
During boot we don’t know what else will run on the system and what
resources will be used, we only know a specific set of predefined assets
to protect e.g. from the Device Tree / ACPI tables*, such as peripherals
we want to isolate from each other or from the OS, reserved memory
regions, the memory of the firmware, sensitive resources such as keys
that we want to protect after using them, the BootROM (a use case that
frequently came up on our discussions) etc. Those assets will always be
there and the rules associated with them are not expected to change
afterwards, in other words the ruleset associated with those assets is
expected to be mostly static. Finally we can have a good idea beforehand
on how large this ruleset will be, since there is a finite number of
those assets in the system.
In contrast when the OS/Hypervisor/Secure monitor runs, it will create,
destroy and modify memory regions on behalf of various applications /
services / peripherals that need protection, so a static ruleset can’t
work there. We also can’t predict how large the various rulesets (for
each application / service / peripheral) will be.
b) Blacklist vs Whitelist approach
When we know what to block but not what to allow during boot, it makes
sense to follow a blacklist policy, in the same way PMP/ePMP is used to
restrict access to M-mode, that by default can access anything, with
locked rules**.
When the OS/Hypervisor/Secure monitor runs and we learn what
applications / services are running on the system, it makes sense to
follow a whitelist policy to isolate them from each other and protect
any related assets, in the same way we create a page table and enable
the MMU once we know e.g. where the kernel is, and switch to virtual
memory.
b) Simple vs Complex implementation / programming model
During boot we need to be able to protect our assets as early as
possible, even before having access to DRAM, and we need the capability
of rule locking so that once a rule is added, it can’t be modified or
removed afterwards (we don’t want anyone -including privileged code- to
be able to un-protect encryption keys for example). We also want to keep
firmware / BootROM code as simple as possible so we want the mechanism
we’ll use during boot to have a simple programming model as well. A
mechanism like PMP/ePMP using arrays of registers for the ruleset is a
good example, we don’t need memory to store in-memory structures like
page tables, no synchronization primitives, we can have an initial
ruleset on the registers on reset, and we can also have rule locking
easily.
On the OS/Hypervisor/Secure monitor we don’t have such limitations and
we can instead focus on providing more features and cover a broader
spectrum of use cases.
It’s clear that we need two separate mechanisms:
- One simple mechanism that we can use as soon as possible to protect a
set of predefined assets, using a mostly static ruleset, under a
blacklist policy
- A more complex mechanism that we can use later on, to provide further
isolation and protection of processes and peripherals, using a dynamic
ruleset, under a whitelist policy
We expect from the IOPMP TG to provide a spec for the first mechanism,
and the IOMMU TG to provide a spec for the second one.
We’d also like to see a recommendation or standardization of who is
responsible (firmware/OS) for managing each unit, to assist in defining
a TCB.
Some further notes:
1) IOPMP and IOMMU are expected to work alongside, complementing each
other. They shouldn’t overlap:
- IOPMP shouldn’t deal with memory translation.
- IOMMU shouldn’t try to provide functionality covered by IOPMP.
2) IOMMU and IOPMP can be used with CPUs with or without memory
translation:
- On a system without memory translation an IOMMU can still provide
protection/isolation by using physical addresses on the page tables (it
can become an IOMPU).
- On a system with memory translation and without an IOMMU, IOPMP can
still provide protection / isolation for the required assets.
In general there is no conflict between the memory protection mechanisms
inside the hart (PMP/ePMP/MMU/MPU) and IOMMU/IOPMP.
3) IOMMU and IOPMP can be used on both embedded and application/server
class systems:
- IOPMP is a simple mechanism so it can be used in most systems.
- IOMMU has various configurations since it supports only first stage,
only second stage, nested or no translation modes. So it’s also suited
for embedded systems by supporting a smaller set of features.
4) IOPMP doesn't necessarily need to sit on the master side, that's an
implementation detail and shouldn't be part of the charter.
*: To get an idea check out ACPI SDEV:
https://uefi.org/specs/ACPI/6.4/05_ACPI_Software_Programming_Model/ACPI_Software_Programming_Model.html#sdev-acpi-table
Or OpenSBI domains:
https://github.com/riscv-software-src/opensbi/blob/master/docs/domain_support.md
**: Note that we added the option of a whitelist policy on ePMP to
assist in some use cases (using it together with RLB on early boot to
gradually “open up” the system), but in practice in the end there’s
going to be a rule there to allow access to the rest of the system for
S/U-modes, so we are effectively creating a blacklist in reverse based
on priority matching (some low-priority rules to allow access to
everything and higher priority rules to restrict that access).
Thanks for your time,
Regards,
Nick
|
Yann Loisel